Head Mounted Displays (HMDs) are becoming increasingly popular for augmented reality (AR) and virtual reality (VR) applications. While many AR systems provide “see-through” transparent or translucent displays upon which to project virtual objects, many VR systems instead employ opaque, enclosed screens. These enclosed screens may completely obscure the user's field of view of the real world. Indeed, eliminating the user's perception of the real world may be integral to a successful VR experience.
Unfortunately, such an opaque view may be dangerous to the user. Particularly, a user engaged in an AR or VR experience using such a headset is likely unaware of the real-world objects in their surrounding. Stepping upon or colliding with such objects may injure the user. Even when such objects are absent, the user may still fail to fully enjoy or participate in the AR or VR experience, as they are constantly in fear of their real-world surroundings. While one could demarcate a cage-like space, or dedicate an entire room to the AR or VR experience, this is likely impractical, and certainly inimical to the design goals of most AR experiences.
Accordingly, there exists a need for systems and methods to easily determine and monitor a safe region within which the user may engage in AR or VR headset activities without fear of collisions. Ideally, such systems and methods would be suitable for headsets whether they employed transparent, translucent, or opaque fields of view. Additionally, such solutions should be sufficiently precise that they can readily ascertain even subtle changes to the environment that may present an unexpected danger to the user.
While the flow and sequence diagrams presented herein show an organization designed to make them more comprehensible by a human reader, those skilled in the art will appreciate that actual data structures used to store this information may differ from what is shown, in that they, for example, may be organized in a different manner; may contain more or less information than shown; may be compressed and/or encrypted; etc.
The headings provided herein are for convenience only and do not necessarily affect the scope or meaning of the embodiments. Further, the drawings have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be expanded or reduced to help improve the understanding of the embodiments. Similarly, some components and/or operations may be separated into different blocks or combined into a single block for the purposes of discussion of some of the embodiments. Moreover, while the various embodiments are amenable to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail below. The intention, however, is not to limit the particular embodiments described. On the contrary, the embodiments are intended to cover all modifications, equivalents, and alternatives falling within the scope of the disclosed embodiments.